“QAC报告怎么生成“以及“QAC报告字段怎么按评审要求调整“，这两个问题一般不是单纯点哪里导出能说清的。真正到了项目评审的时候，评审人员看的并不是页面有多漂亮，而是报告里有没有把事情交代明白：扫描了哪些代码，用了什么规则，发现了哪些问题，哪些问题已经处理完了，哪些做了偏离或抑制，后面由谁负责。所以，生成报告之前，最好先把分析结果、规则配置和评审字段放在一起想清楚。

在QAC工具里，工程导入怎样设置，导入之后头文件又找不到该怎么处理，这两个问题经常是一起出现的。出现这类情况，一般不是因为工具本身不能分析代码，而是由于在导入工程的环节里，编译环境、头文件搜索路径、宏定义和源代码的目录结构没有被完整地带入，结果分析工具在处理源代码时，无法找到需要的头文件。把代码导入QAC工程，并不是简单理解为“把源文件加进来”，更为准确的说法是，要尽量让QAC还原出真实编译器所看到的那套环境。

QAC的增量分析应当怎样配置，以及QAC增量分析的结果不完整又该怎样处理，这是老项目在接入静态分析时很容易碰到的问题。如果每次都跑全量分析，时间会拖得很长，CI流水线也容易被拖慢；但如果只做增量分析，又担心某些受到影响的文件没有被扫描到。QAC的增量分析，更适合用在日常提交、合并请求和分支检查这些场景中，用来尽早地发现新增的问题，但是它不应当完全替代周期性的全量分析。在CI场景下，增量分析通常需要依赖已有的基线，并且着重关注由本次变更所带来的新增问题。

QAC的MISRA检查应当怎样开启，以及QAC的MISRA违规项应该怎样筛选，关键之处不在于把项目导入后仅仅运行一次分析就结束，而在于要先弄清楚项目的语言、编译配置、MISRA版本和规则集这几项是否彼此匹配。Perforce QAC这个工具支持C和C++的静态分析，也支持MISRA规则检查，官方资料里也说明它覆盖了MISRA C与MISRA C++的多个版本，包括MISRA C:2023、MISRA C++:2023等规则体系。

QAC基线怎么建立，还有QAC基线更新以后，历史问题要怎么去做对比，这在使用静态分析的时候，是经常会遇到的问题。很多项目头一回接入QAC的时候，会看到历史代码里面诊断出来的结果特别多，要是要求这一次就全部改干净，开发那边的压力会非常大，实际上也不太容易做得到。基线的用处，就是把现在已经有的那些诊断结果先固定下来，往后再把精力主要放在新增的问题、有变化的问题，还有那些必须得去改的问题上面。Perforce QAC官方文档里面也提到过，基线的诊断抑制功能，是可以在新开发周期刚开始的时候，拿来把旧的诊断警告给抑制掉的。

QAC里面冒出来的误报，应该怎么去处理它，还有给误报打好标记之后，那份要拿来审核的记录，又该怎么给它保留下来，这是把静态代码检查这套东西往项目里用的时候，比较容易碰到的一类情况。QAC给出的告警，它不是每一条都铁定代表代码里就有毛病，但是也不能说，就凭着代码能编译过去、功能测试跑着也没什么问题，就直截了当地把那条告警当成误报给处理了。处理误报这件事，它里头最要紧的那个地方，倒不是要怎么把那一条条的问题，从报告里面给弄消失掉，而是要把问题的性质到底是什么，给分辨清楚，并且得把你是怎么去判断的、那套审核是怎么走过来的，还有跟哪个版本绑在一起的这些个凭据，都一并给留下来。如果不这么去做，那等到后面再去做质量评审、过ASPICE审计，再或者遇上安全合规检查的时候，就很难去说明白，这些告警它当初到底是因为什么，才被允许关掉的了。

想要搞懂QAC的分析结果怎么看，还有分析结果里的调用路径怎么定位，不能只盯着告警的总数量不放；QAC的静态分析结果，一般会按文件、消息等级、规则组、诊断信息这几个维度来展示，使用的人要先分清问题属于哪种类型，是违反了编码规则，是数据流出了问题，是跨模块带来的问题，还是项目配置不对引发的分析异常。Perforce的QAC官方文档里也写了，在图形界面里，可以通过Files、Message Levels、Rule Groups和Analysis Results/Diagnostics这些面板，来查看完整的分析内容。

QAC规则配置要怎么设置，QAC规则配置和项目编码规范要怎么匹配，这类问题在嵌入式C/C++开发项目中经常出现；很多团队最开始只想着把MISRA检查运行起来，等到真正接入工具之后才发现，并不是把所有规则全部打开就可以完成设置。QAC常被用于C/C++代码的静态检测、缺陷排查和编码标准合规校验，在安全关键软件、车载软件这类项目中应用较多，规则配置如果和项目编码规范不相匹配，扫描结果就难以发挥实际作用，开发人员也容易将这款工具视为额外的工作负担。

在嵌入式的C和C++项目里面，QAC报头文件找不到这种事，是挺常见的，它说找不到，往往倒不是代码里面真的就少了那么一个文件，而是在QAC的项目里头，没有拿到跟真实编译时候一模一样的那些包含路径、宏的定义、编译器的选项，还有工程的根目录，按照Perforce Helix QAC的文档说明，项目的文件，是需要从真实的构建环境里面，去把它相关的那些选项给提取出来的；而构建监控这个功能，也会在构建的过程当中，去把那些被编译的文件、它们的路径，还有其它的信息，全给识别下来。

在项目里去看QAC的历史趋势，还有当趋势图上的波动变得不正常了，要怎么去判断，这件事的重点，并不是去盯着某一次扫描的结果在那里看，而是要去观察同一个项目，在不同的构建版本、不同的软件版本，还有用了不同的规则集的情况下，它的质量到底是怎么一步一步发生变化的，Perforce的那个QAC仪表板，它就是被拿来集中地汇总，然后展示QAC分析出来的那些结果的，每一次，你往上面上传了不同的分析结果，它都会形成一个新的快照，有了这些快照，后面才能按照时间，或者是按照构建的记录，去观察趋势是怎么变的，要是一个项目，只是在本地去生成那种一次性的HTML报告，那一般就只能看到当前这独一份的结果了，至于历史的趋势，那是需要靠着持续不断地往上传结果、把配置给统一好，还有一条稳稳当当的基线，这些条件都给凑齐了，才能够看到的。